Creating an Expense Tracker with Charts and Categories

Course: Android App Development

Topic: Creating an Expense Tracker with Charts and Categories

Course Link: Android App Development Course

Demo Link: Register for a Course Demo

Website: JustAcademy

1. Introduction to an Expense Tracker Application

An expense tracker is a mobile application that helps users record daily expenses, organize transactions into categories, monitor income, and understand their spending habits. It presents financial information in a structured format so users can identify where their money goes and make informed budgeting decisions.

In Android development, building an expense tracker is an excellent practical project because it combines user interface design, form validation, database management, application architecture, data visualization, and testing. The application can be developed using Kotlin, Jetpack Compose, Room Database, ViewModel, Kotlin Coroutines, and a charting library.

For example, a user may record ₹250 for lunch, ₹1,200 for transportation, and ₹2,000 for shopping. The app stores each transaction, associates it with a category, calculates totals, and displays a chart showing the distribution of spending.

Objectives of the Project

• Create an interface for adding, editing, viewing, and deleting transactions.
• Organize transactions into categories such as Food, Travel, Shopping, Bills, and Health.
• Store financial records locally using Room Database.
• Calculate total income, total expenses, and remaining balance.
• Display category-wise spending through pie charts or donut charts.
• Show spending trends using daily, weekly, or monthly bar charts.
• Apply validation, error handling, and clean application architecture.

2. Core Features of the Expense Tracker

3. Technologies Used

Room is an abstraction layer over SQLite that simplifies database operations and checks SQL queries at compile time. For further information, refer to the official Room documentation.

4. Planning the Application Architecture

A maintainable expense tracker should separate the interface, business logic, and data storage. The Model-View-ViewModel (MVVM) pattern is a practical choice for this project.

ExpenseTracker/
├── data/
│   ├── entity/
│   │   ├── TransactionEntity.kt
│   │   └── CategoryEntity.kt
│   ├── dao/
│   │   └── TransactionDao.kt
│   ├── database/
│   │   └── ExpenseDatabase.kt
│   └── repository/
│       └── ExpenseRepository.kt
├── ui/
│   ├── dashboard/
│   ├── transactions/
│   ├── categories/
│   └── charts/
├── viewmodel/
│   └── ExpenseViewModel.kt
└── MainActivity.kt

Responsibilities of Each Layer

• UI layer: Displays forms, transaction lists, dashboard summaries, and charts.
• ViewModel layer: Validates user actions, calculates summaries, and exposes screen state.
• Repository layer: Coordinates access to transaction and category data.
• Database layer: Defines entities, data access objects, and Room database configuration.

The UI should not execute SQL queries directly. Instead, user actions are passed to the ViewModel, which calls the repository. The repository accesses the database, and the resulting data is exposed back to the interface. This separation improves testability and maintainability.

5. Designing Transaction and Category Data Models

Each transaction should contain enough information to identify the amount, transaction type, category, date, and description. Categories can be stored separately so that they can be reused across multiple transactions.

5.1 Transaction Entity

import androidx.room.Entity
import androidx.room.PrimaryKey

@Entity(tableName = "transactions")
data class TransactionEntity(
    @PrimaryKey(autoGenerate = true)
    val id: Long = 0,
    val amountInMinorUnits: Long,
    val description: String,
    val categoryId: Long,
    val type: String,
    val dateMillis: Long
)

The amount is stored here in minor currency units, such as paise for Indian rupees, rather than as a floating-point value. This reduces common floating-point rounding problems. For a simple project, the app may alternatively use a carefully defined decimal-money strategy.

5.2 Category Entity

import androidx.room.Entity
import androidx.room.PrimaryKey

@Entity(tableName = "categories")
data class CategoryEntity(
    @PrimaryKey(autoGenerate = true)
    val id: Long = 0,
    val name: String,
    val iconName: String,
    val colorHex: String
)

Example categories include Food, Transport, Shopping, Entertainment, Health, Education, Bills, Salary, and Other. Category names should be managed consistently so that chart totals are not split across duplicate names such as “Food” and “food”.

5.3 Understanding Important Fields

Important: For a more robust schema, add a foreign key from transactions to categories, an index on frequently filtered columns, and an explicit strategy for category deletion. A transaction should not silently become associated with the wrong category.

6. Creating the Data Access Object (DAO)

A Data Access Object (DAO) defines the database operations required by the application. Room generates the implementation of the DAO based on its annotations.

import androidx.room.Dao
import androidx.room.Insert
import androidx.room.Query
import androidx.room.Delete
import androidx.room.Update
import kotlinx.coroutines.flow.Flow

@Dao
interface TransactionDao {

    @Insert
    suspend fun insert(transaction: TransactionEntity)

    @Update
    suspend fun update(transaction: TransactionEntity)

    @Delete
    suspend fun delete(transaction: TransactionEntity)

    @Query(
        "SELECT * FROM transactions ORDER BY dateMillis DESC"
    )
    fun observeTransactions(): Flow<List<TransactionEntity>>

    @Query(
        "SELECT * FROM transactions WHERE categoryId = :categoryId " +
        "ORDER BY dateMillis DESC"
    )
    fun observeByCategory(
        categoryId: Long
    ): Flow<List<TransactionEntity>>
}

Why Use Flow?

A Flow can emit updated transaction lists whenever the observed database data changes. When a user adds or deletes a transaction, the repository can expose the updated list to the ViewModel, which then updates the interface without requiring the user to manually refresh the screen.

7. Creating the Room Database

The Room database connects entities and DAOs. A database instance is generally shared across the application instead of creating a new instance for every operation.

import androidx.room.Database
import androidx.room.RoomDatabase

@Database(
    entities = [
        TransactionEntity::class,
        CategoryEntity::class
    ],
    version = 1,
    exportSchema = true
)
abstract class ExpenseDatabase : RoomDatabase() {
    abstract fun transactionDao(): TransactionDao
}

Configure the database using Room's database builder in an application-level dependency provider or dependency injection module. Avoid enabling destructive migrations in production when user financial records must be preserved. When the schema changes, provide and test an appropriate migration strategy.

8. Implementing the Repository Pattern

The repository provides a clean interface between the ViewModel and the database. It keeps data access details out of the UI and allows the underlying data source to change later if cloud synchronization is introduced.

class ExpenseRepository(
    private val transactionDao: TransactionDao
) {
    fun observeTransactions() =
        transactionDao.observeTransactions()

    suspend fun addTransaction(
        transaction: TransactionEntity
    ) {
        transactionDao.insert(transaction)
    }

    suspend fun updateTransaction(
        transaction: TransactionEntity
    ) {
        transactionDao.update(transaction)
    }

    suspend fun deleteTransaction(
        transaction: TransactionEntity
    ) {
        transactionDao.delete(transaction)
    }
}

In a complete implementation, the repository can also expose category data, date-filtered queries, category totals, and monthly summaries. It should centralize data-related rules instead of duplicating them across multiple screens.

9. Designing the Expense Tracker User Interface

A simple interface should help users record a transaction quickly and understand their current financial position without navigating through many screens.

Recommended Screens

1. Dashboard: Shows total income, total expenses, remaining balance, recent transactions, and a spending chart.
2. Add Transaction: Contains amount, description, transaction type, category, date, and a save button.
3. Transaction History: Displays saved records with search and filtering options.
4. Categories: Allows users to view or manage available categories.
5. Analytics: Shows category-wise spending and spending trends across selected periods.

Example Dashboard Layout

Expense Tracker
--------------------------------
Selected Period: October 2026

Total Income       ₹45,000
Total Expenses     ₹18,500
Remaining Balance  ₹26,500

Spending by Category
[ Pie / Donut Chart ]

Recent Transactions
Food              ₹250
Transport       ₹1,200
Shopping        ₹2,000

[ Add Transaction ]

The figures above are sample values for demonstration. In the actual application, all totals should be calculated from stored transactions and the selected date range.

Jetpack Compose Example

import androidx.compose.foundation.layout.*
import androidx.compose.material3.*
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.unit.dp

@Composable
fun ExpenseSummary(
    income: String,
    expenses: String,
    balance: String
) {
    Column(
        modifier = Modifier
            .fillMaxWidth()
            .padding(16.dp),
        verticalArrangement = Arrangement.spacedBy(12.dp)
    ) {
        Text(
            text = "Expense Tracker",
            style = MaterialTheme.typography.headlineMedium
        )

        Card {
            Column(
                modifier = Modifier.padding(16.dp)
            ) {
                Text("Total Income: $income")
                Text("Total Expenses: $expenses")
                Text("Balance: $balance")
            }
        }
    }
}

This composable demonstrates a basic summary card. A production dashboard should receive values from ViewModel state instead of hardcoding them, and should display loading, empty, and error states where appropriate.

10. Creating the Add Transaction Form

The transaction form is one of the most important components because inaccurate or incomplete entries lead to incorrect financial summaries.

Form Fields

• Amount: Must be numeric and greater than zero.
• Description: Provides a meaningful label, such as “Lunch” or “Electricity bill”.
• Type: Allows the user to choose Income or Expense.
• Category: Selects a valid category from the category list.
• Date: Records the actual transaction date.
• Save button: Validates and stores the record.

Validation Rules

Example Validation Function

data class TransactionFormInput(
    val amountText: String,
    val description: String,
    val categoryId: Long?,
    val type: String
)

fun validateTransaction(
    input: TransactionFormInput
): String? {
    val amount = input.amountText.toBigDecimalOrNull()

    if (amount == null) {
        return "Enter a valid amount."
    }

    if (amount <= java.math.BigDecimal.ZERO) {
        return "Amount must be greater than zero."
    }

    if (input.description.isBlank()) {
        return "Enter a transaction description."
    }

    if (input.categoryId == null) {
        return "Select a category."
    }

    if (input.type !in setOf("INCOME", "EXPENSE")) {
        return "Select a valid transaction type."
    }

    return null
}

For financial accuracy, convert the validated decimal amount into the selected currency's minor units using an explicit rounding policy. Do not rely on a direct floating-point conversion for monetary calculations.

11. Organizing Expenses into Categories

Categories make financial records easier to understand. Instead of reviewing hundreds of transactions individually, a user can compare totals for Food, Travel, Rent, Shopping, and other spending groups.

Common Expense Categories

Category Design Best Practices

• Use consistent names and identifiers.
• Give each category a distinct, accessible icon and color.
• Allow users to add custom categories if the project requires it.
• Prevent accidental duplicate categories.
• Define what happens to existing transactions when a category is renamed or deleted.
• Keep income categories distinct from expense categories, or clearly distinguish transaction types.

12. Calculating Income, Expenses, and Balance

The dashboard should calculate summaries from the underlying transaction records. For a selected period, total income is the sum of income transactions, and total expenses are the sum of expense transactions.

Balance formula:

Balance = Total Income - Total Expenses

For example, if income is ₹45,000 and expenses are ₹18,500, the net difference is ₹26,500.

Sample Calculation

Be clear about the meaning of balance. A simple expense tracker may calculate income minus expenses within the selected period. A true account balance may also require an opening balance, transfers, refunds, and account-specific rules.

13. Querying Category-Wise Expense Totals

Charts need summarized data rather than a raw list of all transactions. The application can calculate category totals in Kotlin or query aggregated results from the database.

Example SQL Query

SELECT
    categoryId,
    SUM(amountInMinorUnits) AS totalAmount
FROM transactions
WHERE type = 'EXPENSE'
    AND dateMillis >= :startDate
    AND dateMillis < :endDate
GROUP BY categoryId
ORDER BY totalAmount DESC;

This query groups expense records by category and calculates the total for a chosen time range. The category identifiers can then be joined with category records to display names, icons, and colors.

Use a start-inclusive, end-exclusive date range. This avoids common errors when filtering by calendar day or month. Calculate date boundaries in the user's intended time zone, particularly when transactions are stored as epoch milliseconds.

Category Summary Model

data class CategoryExpenseSummary(
    val categoryId: Long,
    val categoryName: String,
    val totalAmountInMinorUnits: Long,
    val colorHex: String
)

14. Understanding Charts in an Expense Tracker

Charts turn numerical summaries into visual information. The chart type should match the question the user wants answered.

14.1 Pie Chart

A pie chart divides a circle into slices. Each slice represents one category's proportion of the selected total expenses.

Category percentage formula:

Category Percentage =
    (Category Expense / Total Expenses) * 100

For example, if Food expenses are ₹3,500 and total expenses are ₹18,500:

(3500 / 18500) * 100 = approximately 18.92%

14.2 Donut Chart

A donut chart is similar to a pie chart but contains an empty center. The center can display the total spending amount, while the colored segments represent individual categories. Avoid displaying too many tiny slices; group small categories into “Other” when appropriate.

14.3 Bar Chart

A bar chart is useful for comparing monthly totals. For example, the user can compare spending in July, August, September, and October. All bars should use the same scale so that differences are easy to interpret.

14.4 Choosing a Charting Library

Developers may use a charting library compatible with their chosen UI framework, such as a Compose-compatible chart library. Check its current documentation, maintenance status, supported Compose versions, and licensing before adding it to a production project.

Chart data should be generated from database summaries, not from hardcoded example values. Keep the chart's labels, legend, currency formatting, and accessible descriptions synchronized with the selected filters.

15. Preparing Data for a Pie Chart

Before rendering a pie chart, filter the transactions to include only expenses within the selected period. Then group the records by category, sum the amounts, and calculate each category's percentage of the total.

data class ChartSlice(
    val categoryName: String,
    val amountInMinorUnits: Long,
    val percentage: Float,
    val colorHex: String
)

fun calculatePercentage(
    categoryTotal: Long,
    totalExpenses: Long
): Float {
    if (totalExpenses <= 0L) return 0f

    return (
        categoryTotal.toDouble() /
        totalExpenses.toDouble() * 100.0
    ).toFloat()
}

Use the function only with valid, non-negative expense totals. For a real chart, compute the total and category totals using the same period, currency, and filtering rules. Avoid division by zero when there are no expenses.

Example Chart Data

16. Connecting Charts to Reactive UI State

The dashboard should respond automatically when a transaction is inserted, updated, or deleted. A typical implementation exposes a stream of database records or summary data from the repository through the ViewModel.

import androidx.lifecycle.ViewModel
import androidx.lifecycle.viewModelScope
import kotlinx.coroutines.flow.SharingStarted
import kotlinx.coroutines.flow.stateIn

class ExpenseViewModel(
    repository: ExpenseRepository
) : ViewModel() {

    val transactions = repository
        .observeTransactions()
        .stateIn(
            scope = viewModelScope,
            started = SharingStarted.WhileSubscribed(5000),
            initialValue = emptyList()
        )
}

This example exposes the transaction list as a state stream. In a full application, create a dedicated dashboard state that includes income, expense totals, category summaries, the selected period, and loading or error information.

In Jetpack Compose, collect the ViewModel's state using lifecycle-aware collection where available. This keeps the interface synchronized with the data while respecting the screen lifecycle.

17. Filtering Transactions by Date

Date filtering allows users to view daily, weekly, monthly, or custom-period spending. It also ensures that dashboard figures and charts describe the same period.

Recommended Filters

• Today: Transactions within the current local calendar day.
• This week: Transactions within the chosen week definition.
• This month: Transactions from the first day of the month to the first day of the next month.
• Custom range: Transactions between a user-selected start and end date.

Use a clearly defined time zone for calendar boundaries. The query should generally use a start-inclusive and end-exclusive interval so that transactions at midnight are handled correctly.

18. Displaying Transaction History

The transaction history screen provides a readable list of saved financial records. Each row can display the category icon, description, date, amount, and transaction type.

Food
Lunch at office
28 Oct 2026                         -₹250

Transport
Monthly travel pass
27 Oct 2026                       -₹1,200

Salary
Monthly salary
25 Oct 2026                      +₹40,000

Use LazyColumn in Jetpack Compose for long lists because it composes visible items efficiently. Add edit and delete actions with clear confirmation where appropriate. For large datasets, consider pagination or database-level filtering instead of loading every record into memory.

19. Handling Empty and Error States

A reliable financial app must communicate clearly when it has no data or cannot complete an operation.

20. Testing the Expense Tracker

Testing verifies that transaction storage, calculations, categories, and charts remain correct as users interact with the application.

Unit Testing

• Verify that income and expense totals are calculated correctly.
• Check that a category percentage is correct for a known total.
• Confirm that zero total expenses do not cause division errors.
• Validate rejection of empty descriptions and invalid amounts.
• Check that date filters include the correct records.

Database Testing

• Insert a transaction and verify that it can be retrieved.
• Update a record and check that the changed amount is displayed.
• Delete a transaction and confirm that totals are recalculated.
• Verify that category references remain valid.
• Test database migrations when the schema changes.

UI Testing

• Confirm that users can navigate between dashboard, history, and form screens.
• Check that chart labels and legends are readable.
• Test forms on different screen sizes and font scales.
• Verify empty states and validation messages.
• Confirm that adding a transaction refreshes the visible totals and chart.

21. Common Problems and Troubleshooting

22. Security, Privacy, and Reliability

Financial records can contain sensitive personal information. Even a simple offline expense tracker should follow privacy-conscious design principles.

• Store only the information needed for the application's features.
• Do not log transaction descriptions, amounts, or other sensitive financial details in production logs.
• Use secure device practices and consider whether app-level authentication or device authentication is appropriate.
• Clearly explain whether data remains local or is synchronized to a server.
• If cloud synchronization is introduced, secure network communication and enforce appropriate access controls.
• Use backups carefully because exported files may expose private financial information.
• Handle category deletion and schema upgrades without unintentionally losing transaction history.

23. Performance and User Experience Best Practices

• Use Room queries to aggregate data instead of repeatedly calculating large summaries on the main thread.
• Use Coroutines for database writes and other potentially long-running operations.
• Observe only the data needed by each screen.
• Use LazyColumn for large transaction lists.
• Keep charts readable with a limited number of meaningful categories.
• Display currency consistently and label the selected reporting period.
• Provide accessible descriptions and do not rely on color alone to distinguish chart segments.
• Prevent accidental duplicate submissions when the user taps Save repeatedly.
• Confirm destructive actions and provide clear feedback after saving or deleting records.
• Use a single source of truth for totals so that dashboard cards and charts cannot disagree.

24. Practical Project: Build a Complete Expense Tracker

Project Requirements

Create an Android application that allows users to record income and expenses, assign categories, view transaction history, and analyze their spending with charts.

Implementation Steps

1. Create a Kotlin Android project in Android Studio.
2. Set up Jetpack Compose and Material 3 for the interface.
3. Add Room dependencies and configure database entities, DAOs, and the database class.
4. Create default categories such as Food, Transport, Shopping, Housing, and Bills.
5. Implement a repository to handle transaction and category operations.
6. Create a ViewModel to expose transaction lists, totals, and category summaries.
7. Build the dashboard with income, expense, and balance cards.
8. Build the add/edit transaction form with validation.
9. Implement transaction history, editing, deletion, and date filters.
10. Query category-wise totals and display them in a pie or donut chart.
11. Add a monthly bar chart to compare spending over time.
12. Test calculations, database operations, filtering, and UI behavior.
13. Verify that data remains available after the application is closed and reopened.

Expected Output

• A working dashboard that displays calculated financial summaries.
• A transaction form that validates and saves user entries.
• A category-based transaction history.
• A chart showing the distribution of expenses.
• A monthly spending report.
• A locally persisted transaction database.

25. Possible Future Enhancements

• Monthly budgets: Allow users to set category-specific spending limits.
• Budget notifications: Notify users when they approach a configured budget limit.
• Recurring transactions: Support regular rent, subscriptions, and salary entries.
• CSV export: Allow users to export transaction history for personal analysis.
• Cloud backup: Add secure synchronization between devices.
• Multiple accounts: Separate cash, bank accounts, and wallets.
• Advanced analytics: Compare categories and spending trends across periods.
• Search and filters: Find records using descriptions, amounts, categories, and dates.

26. Interview Questions and Answers

Q1. What is an expense tracker application?

An expense tracker is an application that records income and expenses, categorizes transactions, calculates financial summaries, and helps users analyze their spending habits.

Q2. Why is Room Database useful in an Android expense tracker?

Room simplifies SQLite database access through entities, DAOs, and database classes. It supports structured local persistence and compile-time validation of many SQL queries.

Q3. Why should transactions have categories?

Categories group related records, simplify filtering, and allow the application to calculate and visualize spending by purpose.

Q4. What is the purpose of a pie chart?

A pie chart represents the proportions of a total. In an expense tracker, it can show what percentage of spending belongs to each category.

Q5. When is a bar chart more useful than a pie chart?

A bar chart is often more useful when comparing amounts across several categories or time periods, such as monthly expenses.

Q6. What is MVVM?

MVVM stands for Model-View-ViewModel. It separates UI rendering from screen state and data logic, improving maintainability and testability.

Q7. How can the chart update when a transaction changes?

The database can expose a Flow of transaction or summary data. The ViewModel collects that data and exposes updated UI state, allowing the chart to re-render when values change.

Q8. How do you calculate the net difference?

Subtract total expenses from total income for the selected period. If the application also tracks opening balances and transfers, the balance calculation must account for those separately.

Q9. How should monetary values be stored?

Use integer minor units or an appropriate decimal representation with explicit rounding rules. Avoid relying on binary floating-point values for financial calculations.

Q10. How do you prevent incorrect category totals?

Filter records by transaction type and date range, group them by category identifier, and calculate totals using consistent currency and date-boundary rules.

Q11. Why should database operations not run on the main thread?

Long-running operations on the main thread can make the interface unresponsive. Coroutines and appropriate database APIs allow operations to run asynchronously.

Q12. How can you test the expense tracker?

Write unit tests for calculations and validation, database tests for CRUD operations, and UI tests for forms, navigation, filters, chart states, and updated summaries.

27. Quick Revision Checklist

• Understand the features and architecture of an expense tracker.
• Create transaction and category data models.
• Implement Room entities, DAOs, and database configuration.
• Use a repository to separate data access from UI logic.
• Build the interface with Jetpack Compose.
• Validate transaction amounts, descriptions, categories, and types.
• Calculate income, expenses, and balance consistently.
• Group expenses by category for charts.
• Implement pie, donut, or bar charts using real database data.
• Support date filters and reactive updates.
• Test edge cases such as zero expenses, empty data, and invalid input.
• Protect financial information and preserve records during database upgrades.

28. Conclusion

Creating an expense tracker with charts and categories is a practical Android development project that combines Kotlin, Jetpack Compose, Room Database, MVVM architecture, reactive state management, and data visualization. By structuring transactions correctly, organizing expenses into meaningful categories, and calculating summaries consistently, developers can build an application that is useful, reliable, and maintainable.

The most important principles are to persist records properly, validate user input, calculate monetary values accurately, keep the UI synchronized with database changes, and make charts reflect the same filters and totals as the dashboard. These skills also provide a strong foundation for developing budgeting tools, personal finance dashboards, and other data-driven Android applications.

29. Additional Learning Resources

• Android Developers: Room Database
• Android Developers: Jetpack Compose
• Android Developers: App Architecture
• Explore the Android App Development Course at JustAcademy
• Register for a JustAcademy Course Demo
• Visit the JustAcademy Website